An Investigation into Constraint Modeling of Realistic Planning Domains

Constraint Programming provides a natural way to encode combinatorial search problems. AI Planning problems can also be encoded as constraint-based search procedures. We propose an encoding of planning problems as constraint models and infer actions from state transitions. This approach provides a simple, compact encoding of the planning problems. We illustrate the encoding in a manufacturing planning domain. Introduction Constraint Programming (CP) is the programming paradigm that is said to be closest to the programming holy grail, i.e. the user describes the problem (models = variables + variables’ domains + constraints) and the computer solves it (solving = search + constraint propagation). In constraint programming problems are formulated as constraint satisfaction problems (CSPs). It captures the problem domain’s features in a natural and intuitive way. CP approaches have been used in solving many real world combinatorial search problems. AI Planning is a problem where an initial state, desired (partial) goal state and a set of operator descriptions are given and the task is to synthesize a sequence of actions to transform the initial state into a goal state. In classical planning, operators or actions are often described in STRIPS style, using three lists: preconditions, an add list and a delete list. The preconditions state which propositions must hold before an operator can be applied; the add and delete lists describe which propositions become true and which become false after applying the operator. Both Constraint Programming and AI Planning are search problems. In constraint programming, search attempts to find a labelling of all variables consistent with the given constraints, optionally while trying to optimise for some objective function. CP search algorithms typically separate issues of variable selection (choosing which variable to branch on next), domain reduction (how to narrow the domain of the chosen variable on a search branch), and propagation (inferring necessary domain reductions on other variables as a consequence). Propagation can dramatically reduce the search space. AI planning algorithms, on the other hand, Copyright c © 2007, Association for the Advancement of Artificial Intelligence (www.aaai.org). All rights reserved. usually take a dynamic approach to problem solving by introducing new subgoals on different search paths. One weakness of this approach is that it is much harder to perform effective propagation. In ordinary CP, all decision variables and their domains are defined as part of the problem model. In ordinary AI planning, one does not know in advance what the decision variables are (here we are using “decision variable” to denote the state of something at a given time or whether a particular action is to be carried out at a given time). A CP representation of an AI planning problem therefore has to address the issue of plan length from the outset. There are two basic solutions: iterative deepening (search for a plan of length 1, search for a plan of length 2, ...) or placing an upper bound on the plan length and filling trailing action steps with “do nothing” actions. Searching for a predefined length of plan is known as bounded length planning. In many real world planning problems, an upper bound on plan length can often be found. Interest in constraint techniques in AI planning has grown in recent years. Using constraint-based search for AI Planning has shown good results, especially in parallel optimal planning domains. Kautz and Selman ( 1992; 1996) first proposed a SAT encoding of the planning problems. Using the planning graph (Blum & Furst 1995) as a basis for encoding proved to be helpful as it significantly reduces the size of the SAT representation (Kautz & Selman 1999). While SAT is restricted to Boolean variables, others have extended the encoding into more general CSP based framework (Do & Kambhampati 2001). There are other approaches as well, for instance Integer Programming (Vossen et al. 1999), (van den Briel & Kambhmpati 2005) and Constraint Programming (van Beek & Chen 1999). The basic idea is to convert a STRIPS style planning problem into a form suitable for constraint-based search by encoding the initial states, goal states, actions, frame axioms and mutual exclusion relations as constraints for a given bounded length plan. A detailed survey of applications of constraint in AI planning is given in (Nareyek et al. 2005). In this paper we investigate how we can model planning domains in the constraint model. The constraint modeling language we have used is MiniZinc (Nethercote et al. 2007), a subset of a more powerful constraint modeling language Zinc (de la Banda et al. 2006) developed as part of the G12 project (Stuckey et al. 2005). Here we have modeled a realistic planning problem using MiniZinc in a different way than the standard constraint based encodings. Instead of transforming the STRIPS-style action descriptions of the planning problem, we encode the planning problem based on initial state, goal state and the constraints on state transitions captured from the natural description of the domain. Actions are then inferred from the state transitions. The next section of this paper describes alternative encoding of the planning problems as constraint models. Then the process of encoding is explained in greater detail with a real world planning problem. The last two sections discuss the related work and future work respectively. Alternative Encoding In STRIPS-style planning, state transitions are effected by actions. For example in a transportation domain we can have a “Move” action that transports objects from one location to another. There may be multiple ways to model the actions and objects in a planning domain. Detailed representation of the action is up to the domain modeller (e.g., in some formal language like PDDL (AIPS-98 Planning Competition Committee 1998)) and good modeling is an art. So for a given problem we can have different domain models and the performance of planning algorithms may vary for different models. Generally it is not an easy task to design a planning domain from a given natural-language description of the problem. On the other hand most descriptions include constraints that describe what makes a state valid or invalid. For example in the Blocks-World domain it is easy to extract the following constraints: no two blocks can occupy the same location at the same time; a block can only be moved if it is clear; a block can only move to a clear space. Along with the initial and goal state specifications, these constraints would be enough to define any standard Blocks-World problem. We can define a high level “Move” action that moves a block from one location to the other and infer its applicability based on the state transitions. For example if a block B was on the table at time step t and at next time step it is on top of another block A, then we can infer that at time step t a “Move” action took place that moved the block B from the table to the top of A. This “Move” action could be decomposed into “Pickup” and “Putdown” actions, hence we can have different abstraction levels for an action description. The simplicity of modeling a planning problem using the domain constraints and inferring actions from the state transitions motivates us to explore the alternative encoding for the planning problems. Expressing the STRIPS-style encoding in a constraint modeling language like MiniZinc is non-trivial and feels unnatural. Modeling a planning problem using the domain objects, relations between the objects and a set of constraints of the domain is simple and natural in MiniZinc. The constraints include the initial states of objects, the object states that satisfy the goal, and intermediate constraints that describes which state transitions are legal. Here planning can be seen as abductive plan reconstruction where we can infer a sequence of actions from state transitions. We explain the encoding next by encoding a realworld planning problem. A Realistic Planning Domain We have modeled the Manufacturing Plant domain, which is part of the Knowledge Engineering Competition 2007 (ICKEPS 2007), with the proposed encoding above. This domain can be seen as a variant of the Job Shop Scheduling problem. A plant manufactures products that need one or more attributes. Machines in the plant are connected to each other in some configuration. There are three kinds of machines; Inputs, Outputs and Work machines. Inputs and Outputs do not make attributes and can contain any number of products in them at any point in time. Each Work machine makes one kind of attribute and can contains at most one product at a time. The goal is to find a schedule for the products moving them from the Input machines, through the Work machines (adding the required attributes) and finishing in Output machines. This problem is in the intersection of planning and scheduling (Ruml, Do, & Fromherz 2005). The planning component is required to find paths through the machines and determine which machines should add attributes. For each product there is a set of machines that it must to go through to acquire the required attributes, but these machines may not be connected directly to each other. In this cases products need to find paths via other machines. There are many possible paths for a product, so for each product there can be many possible plans that achieve the goals of the products. The scheduling side of the problem is to schedule each product’s path considering the paths of other products in the system, trying to minimize the overall finishing time. The scheduling component needs to respect the mutual resource use of the plans. In this domain the only resource is the Work machines. Constraint Model of Manufacturing Plant Domain To model the Manufacturing Plant problem as a constraintstate transition system, we have made two relaxations of the real problem description. We assume all the actions take unit time and all the products are in the Input machines at the initial state. Domain Description. Modeling a planning problem as a constrained-state transition system has three main parts: 1) domain objects, 2) constraints between domain objects and 3) constraints on the behaviour of objects. The Manufacturing Plant domain has the following domain objects: Time, Machines, Products, Attributes, and Connections between machines. Each object is defined with its total number in the domain and the set of the instances of the object. Time defines the upper bound of the time needed to finish all products. In MiniZinc objects are represented as follows: int: timesteps; int: nMachines; int: nProducts;